1.2 .NET unter die Lupe genommen 

Mit .NET hat Microsoft im Jahr 2002 eine Entwicklungsplattform veröffentlicht, die inzwischen von vielen Entwicklungsteams akzeptiert und auch eingesetzt wird. Kommerzielle Gründe spielten für Microsoft sicherlich auch eine Rolle, damals einen Neuanfang in der Philosophie der Softwareentwicklung herbeizuführen.

1.2.1 Das Entwicklerdilemma 

In den Jahren zuvor hatte sich aber bereits abgezeichnet, dass sich die Ansprüche an moderne Software grundlegend ändern würden. Das Internet spielte dabei wohl die wesentlichste Rolle, aber auch die Forderung, dem erhöhten Aufkommen clientseitiger Anfragen an einen Zentralserver durch skalierbare Anwendungen zu begegnen. Der Erfolg von Java, das sich in den Jahren zuvor als eine der bedeutendsten Programmiersprachen etabliert hatte, mag der Beweis dafür sein, denn Java spielt seine Stärken in erster Linie bei der Entwicklung webbasierter und verteilter Anwendungen aus.

Die damaligen Probleme waren nicht neu, Technologien gab es bereits schon länger – auch bei Microsoft. Mit COM/COM+ ließen sich zwar auch vielschichtige und skalierbare Anwendungen entwickeln, aber unzweifelhaft war die Programmierung von COM+ wegen der damit verbundenen Komplexität als nicht einfach zu bezeichnen. Es gibt nicht sehr viele Entwickler, die von sich behaupten können, diese Technologie »im Griff« gehabt zu haben. Damit trat auch ein Folgeproblem auf, denn grundsätzlich gilt: Je komplizierter eine Technologie ist, desto fehleranfälliger wird die Software. Man muss nicht unbedingt ein Microsoft-Gegner sein um zu sagen, dass selbst der Urheber dieser Technologien diese oft nur unzureichend in den hauseigenen Produkten umsetzt.

Dass die Vorteile der.NET-Systemplattform nur der Entwicklung verteilter Systeme wie dem Internet zugute kommen, beschreibt nur völlig unzureichend ihre Möglichkeiten. Selbstverständlich lassen sich auch einfache Windows- und Konsolenanwendungen auf Basis von .NET entwickeln. Die Vorteile beziehen sich aber nicht nur auf Anwendungen selbst, sondern lösten auch ein Dilemma der Entwickler. Die Entscheidung für eine bestimmte Programmiersprache war in der Vergangenheit fast schon eine Glaubensfrage – nicht nur, was die Programmiersprache angeht, denn die Festlegung auf eine bestimmte Sprache war auch die Entscheidung für eine bestimmte Funktions- bzw. Klassenbibliothek.

Windows-Programme basieren alle auf der Systemschnittstelle einer Funktionssammlung, die als WinAPI-32 bezeichnet wird. Da diese Funktionssammlung einige tausend Funktionen enthält, wurden verwandte Funktionalitäten in Klassen zusammengeführt und konnten über Methodenaufrufe angesprochen werden. Dieses Prinzip vereinfachte die Programmierung deutlich, aber bedauerlicherweise gab es nicht nur eine einzige, sondern gleich mehrere herstellerspezifische Klassenbibliotheken, die zwar ein ähnliches Leistungsspektrum aufwiesen, aber grundlegend anders definiert waren. Die Microsoft Foundation Classes (MFC) für Visual C++ ist die Klassenbibliothek von Microsoft, Borland-Inprise kochte mit der Object Windows Library (OWL) ein eigenes Süppchen. Der Wechsel von einer Programmiersprache zu einer anderen bedeutete in der Regel auch, sich in eine andere Bibliothek einzuarbeiten. Beides Faktoren, die nicht nur mit sehr viel Zeit kosten, sondern auch finanziellen Aufwand bedeuteten.

Es mag fast erstaunen (oder auch nicht), dass es neben Windows tatsächlich auch noch andere Betriebssysteme gibt, denen man durchaus auch eine Existenzberechtigung zuschreiben muss. Die Entwickler von Java haben das schon vor Jahren erkannt und mit der Virtual Machine (VM) eine Komponente bereitgestellt, die auf verschiedene Betriebssystemplattformen portiert werden kann. Dies ist einer der größten Vorteile von Java und hat sicherlich viele Entscheidungsträger in den Unternehmen beeinflusst. Code lässt sich auf Windowsplattformen entwickeln und auf einer UNIX-Maschine installieren – ein reizvoller Gedanke, Investitionen von einem bestimmten System zu lösen, und nicht etwa daran zu binden.

1.2.2 .NET – Ein paar allgemeine Eigenschaften 

Es ist kein Zufall, dass im vorherigen Abschnitt öfters Java erwähnt worden ist. Wenn Sie das Konzept von Java kennen oder vielleicht in der Vergangenheit sogar mit Java programmiert haben, werden Sie sehr viele Parallelelen zu .NET erkennen. Microsoft ist in der Vergangenheit sicher nicht entgangen, worauf der Erfolg von Java zurückzuführen ist. In Kenntnis der Fakten hat man die Idee, die hinter Java steckt, übernommen und dabei versucht, die bekannten Schwachstellen des Ansatzes bzw. der Sprache auszumerzen. Es darf sich bei Ihnen jetzt allerdings nicht die Meinung festigen, .NET sei nur eine Kopie von Java – .NET hat die Messlatte spürbar höher gelegt.

Wir wollen uns nun ansehen, welche wesentlichen programmiertechnischen Neuerungen .NET mit sich bringt.

Objektorientierung .NET ist 100  %-ig objektbasiert und bildet eine konsistente Schicht zur Anwendungsentwicklung. Es gibt keine Elemente, die sich nicht auf Objekte zurückführen lassen. Sogar so einfache Datentypen wie der Integer werden als Objekte behandelt. Auch Zugriffe auf das darunter liegende Betriebssystem werden durch Klassen gekapselt.

WinAPI-32-Ersatz Langfristig beabsichtigt Microsoft, das Win32-API durch die Klassen des .NET Frameworks zu ersetzen. Damit verwischen auch die charakteristischen Merkmale der verschiedenen Sprachen. Ob eine Anwendung mit Visual Basic .NET programmiert wird oder mit C# oder C++ – es spielt keine Rolle mehr. Alle Sprachen greifen auf die gleiche Bibliothek zurück, sprachspezifische, operative Bibliotheken gibt es nicht mehr. Die Konsequenz ist, dass die Wahl für eine bestimmte Sprache nicht mehr der Entscheidung gleichzusetzen ist, wie effizient eine Anwendung geschrieben werden kann oder was sie zu leisten imstande ist.

Plattformunabhängigkeit Anwendungen, die auf .NET basieren, laufen in einer Umgebung, die mit der virtuellen Maschine von Java verglichen werden kann, in der erst zur Laufzeit einer Anwendung der Maschinencode erzeugt wird. Die Spezifikation der Laufzeitumgebung (Common Language Runtime – CLR) ist keine geheime Verschlusssache von Microsoft, sondern offen festgelegt. In letzter Konsequenz bedeutet das aber auch, dass sich die Common Language Runtime auch auf Plattformen portieren lässt, die nicht Windows heißen, z.B. UNIX oder Linux. Als Beweis kann hier das Projekt Mono genannt werden, mit dem .NET erfolgreich auf die Linux-Plattform portiert worden ist.

Sprachunabhängigkeit Es spielt keine Rolle, in welcher Programmiersprache eine Komponente entwickelt wird. Eine in C# 2005 geschriebene Klasse kann aus VB.NET, J# oder jeder anderen .NET-konformen Sprache heraus aufgerufen werden, ohne den Umweg über eine spezifizierte Schnittstellentechnologie wie COM/COM+ gehen zu müssen. Darüber hinaus lässt sich beispielsweise eine in Visual C# implementierte Klasse auch aus einer VB.NET-Klasse ableiten – oder umgekehrt.

Speicherverwaltung Die Freigabe von nicht mehr benötigtem Speicher war schon immer ein Problem. Unter .NET braucht sich ein Entwickler darum nicht mehr zu kümmern, da der im Hintergrund arbeitende Prozess des Garbage Collectors diese Aufgaben übernimmt und nicht mehr benötigte Objekte erkennt und automatisch aus dem Speicher entfernt.

Weitergabe Ein .NET-Programm weiterzugeben ist viel einfacher geworden – insbesondere im Vergleich zu einem auf COM basierenden Programm, das Einträge in die Registrierungsdatenbank vornehmen muss. Im einfachsten Fall reicht es vollkommen aus, ein .NET-Programm (EXE- oder DLL-Datei) in das dafür vorgesehene Verzeichnis zu kopieren. Darüber hinaus ist aber auch die Verteilung mit einem Installationsassistenten und, ganz neu unter .NET 2.0, mit ClickOnce möglich.

1.2.3 Das Sprachenkonzept 

Die drei Entwicklungssprachen, die in der Vergangenheit hauptsächlich das Bild in der Anwendungsentwicklung prägten, waren C++, Java und Visual Basic 6.0. Seit dem Jahr 2002 und dem Erscheinen des .NET Frameworks 1.0 gesellten sich dazu noch die .NET-Sprachen, allen voran C#.

Betrachten wir jetzt nur die drei zuerst genannten Sprachen. Nehmen wir an, wir würden mit jeder ein einfaches, ausführbares Programm schreiben. Wie sehen die Kompilate dieser drei Sprachen aus und wie werden die drei Compilate ausgeführt, wenn wir sie auf einen Rechner kopieren, auf dem nur das Betriebssystem installiert ist?

Nach der Kompilierung des C/C++-Quellcodes erhalten wir eine .exe-Datei, die beispielsweise durch einen einfachen Doppelklick im Explorer des frisch installierten Rechners gestartet werden kann. Das Compilat wird jedoch auf einer anderen Plattform nicht lauffähig sein, denn dazu wäre zuerst eine Neukompilierung erforderlich.

Eine mit dem VB6-Compiler erzeugte ausführbare Datei kann auf unserer jungfräulichen Betriebssysteminstallation nicht sofort gestartet werden, obwohl die Dateiendung .exe lautet. Wir benötigen zur Ausführung einen Interpreter, das Laufzeitmodul von Visual Basic, der uns den kompilierten Zwischencode in den ausführbaren nativen CPU-Maschinencode übersetzt. Die Portierung eines VB-Programms auf eine andere Plattform ist nicht möglich.

Java arbeitet prinzipiell ähnlich wie Visual Basic 6.0. Es wird ein Zwischencode generiert, der sogenannte Bytecode. Die kompilierten Dateien haben die Dateiendung .class. Zur Laufzeit wird dieser Code zuerst durch einen Interpreter geschickt, der als virtuelle Maschine (VM) bezeichnet wird. Vorausgesetzt, die VM wurde bei der Installation des Betriebssystems installiert, kann man die Java-Anwendung starten. Das Kompilat ist sogar plattformunabhängig und kann auch auf andere Systeme verteilt werden.

Insbesondere die Plattformunabhängigkeit des Kompilats ist bisher ein deutliches Argument für viele Unternehmen gewesen, nicht nur in heterogenen Umgebungen verstärkt auf Java zu setzen.

Entwickeln wir eine .NET-basierte Anwendung, ähnelt der Ablauf der Kompilierung bis zum Start der Laufzeit dem unter Java. Zuerst wird ein Zwischencode erzeugt, der CPU-unabhängig ist. Die Dateiendung lautet .exe, wenn wir eine eigenstartfähige Anwendung entwickelt haben. Allerdings ist diese Datei nicht ohne weiteres lauffähig. Sie benötigt zur Laufzeit einen »Endcompiler«, der den Zwischencode in nativen, plattformspezifischen Code übersetzt. Der Zwischencode einer .NET-Anwendung wird als MSIL-Code (Microsoft Intermediate Language) oder nur kurz als IL bezeichnet, der Endcompiler als JIT-Compiler (Just-In-Time) oder auch nur kurz als JITter.

Hier klicken, um das Bild zu vergrößern

Abbildung 1.1   Der Ablauf der Entwicklung eines .NET-Programms bis zur Laufzeit

1.2.4 Die »Common Language Specification« (CLS) 

Wenn Sie sich den Prozessablauf vom Quellcode bis zur Ausführung einer .NET-Anwendung in Abbildung 1.1 ansehen, müssten Sie sich sofort die Frage stellen, wo der Unterschied im Vergleich zu einer Java-Anwendung zu finden ist – das Diagramm scheint, bis auf die Namensgebung, austauschbar zu sein. Dabei lassen wir andere spezifische Merkmale der beiden Umgebungen außer Betracht, die bei einer genaueren Analyse auch eine Rolle spielen würden.

Vielleicht ist es Ihnen nicht aufgefallen, aber ich habe die Worte .NET-Anwendung und Java-Anwendung benutzt – eine kleine Nuance mit weitreichender Konsequenz. Eine Java-Anwendung ist, darauf weist schon der Name hin, mit der Programmiersprache Java entwickelt worden, eine .NET-Anwendung hingegen ist nicht sprachgebunden. Sicher, in diesem Buch werden wir uns mit Visual C# beschäftigen, aber es macht praktisch keinen Unterschied, ob die Anwendung in Visual C# 2005, in Visual Basic 2005 oder J# entwickelt worden ist. Ausschlaggebend ist am Ende des Kompiliervorgangs nur ein kompatibler IL-Code, ungeachtet der zugrundeliegenden Sprache.

Um sprachunabhängigen Code erzeugen zu können, muss es Richtlinien geben, an die sich alle .NET-Sprachen halten müssen, um ein Fiasko zu vermeiden. Diese Richtlinien, in denen die fundamentalen Eigenschaften einer .NET-kompatiblen Sprache festgelegt sind, werden durch die Common Language Specification (CLS) beschrieben. Die Common Language Specification ist ein offener Standard. Das hatte schon frühzeitig zur Folge, dass lange vor der offiziellen Einführung von .NET viele Softwareunternehmen andere Sprachen, beispielsweise Delphi, Eiffel und Cobol, auf .NET portiert haben.

Wenn alle Sprachen tatsächlich gleichberechtigt sind und dasselbe Ergebnis liefern, stellt sich natürlich die Frage, warum es zukünftig nicht nur eine Sprache geben soll. Sogar Microsoft bietet mit C#, J#, C++ und VB .NET im Visual Studio vier verschiedene an. Der Grund ist recht einfach: Man möchte den Entwicklern nicht eine vollkommen neue Sprache aufzwingen, sondern ihnen die gewohnte sprachspezifische Syntax lassen.

Wenn Sie nun anmerken sollten, dass es sich bei C# um eine völlig neue Sprache handelt, die mit der Veröffentlichung des .NET Frameworks zur Verfügung gestellt worden ist, haben Sie vollkommen Recht. Allerdings assoziiert bereits der Name C# unzweifelhaft, dass die Wurzeln in C/C++ zu finden sind.

Die Konsequenzen, die sich aus der CLS ergeben, sind weitreichend – nicht für den Endanwender, den es nicht im geringsten interessiert, in welcher Sprache seine Applikation entwickelt wird, sondern vielmehr für ein heterogenes Entwicklerteam in einem Softwareunternehmen. Die Entscheidung, eine Anwendung basierend auf .NET zu entwickeln, ist keine Entscheidung für oder gegen eine Sprache – es ist eine konzeptionelle Festlegung. Die Bedeutung der einzelnen Sprachen rückt in den Hintergrund, denn die Komponenten, die in einer .NET-konformen Sprache geschrieben sind, können problemlos miteinander interagieren. Eine Klasse, die in C# geschrieben ist, kann von einer Klasse in Visual Basic 2005 beerbt werden. Beide Klassen können Daten miteinander austauschen und Ausnahmen weiterreichen. Es gibt unter .NET keine bevorzugte Programmiersprache.

Hier klicken, um das Bild zu vergrößern

Abbildung 1.2   Die Common Language Specification als Basis der Sprachunabhängigkeit

1.2.5 Das »Common Type System« (CTS) 

Jede Entwicklungsumgebung beschreibt als eines ihrer wichtigsten Merkmale ein Typsystem, in dem einerseits Datentypen bereitgestellt werden und andererseits Vorschriften definiert sind, nach denen ein Entwickler die standardmäßigen Typen durch eigene erweitern kann. Darüber hinaus muss auch eine Regelung getroffen werden, wie auf die Typen zugegriffen wird.

Mit dem Common Type System (CTS) der .NET-Plattform wird die sprachübergreifende Programmentwicklung spezifiziert und sichergestellt, dass Programmcode unabhängig von der zugrundeliegenden Sprache miteinander interagieren kann. Damit legt das Common Type System die Grundlage für die im vorhergehenden Abschnitt erläuterte Sprachunabhängigkeit.

Alle Typen, die unter .NET zur Verfügung gestellt werden, lassen sich in zwei Kategorien aufteilen:

Wertetypen

Referenztypen

Wertetypen werden auf dem Stack abgelegt. Zu ihnen gehören die in der Entwicklungsumgebung eingebauten ganzzahligen Datentypen und die Datentypen, die Fließkommazahlen beschreiben. Referenztypen werden hingegen auf dem Heap abgelegt. Zu ihnen gehören unter anderem die aus den Klassen erzeugten Objekte.

Obwohl Wertetypen im ersten Moment nicht den Anschein erwecken, von der .NET-Laufzeitumgebung als Objekte behandelt zu werden, ist das kein Widerspruch zu der vorher gemachten Aussage, dass .NET nur Objekte kennt. Tatsächlich erfolgt zur Laufzeit eine automatische Umwandlung von einen Werte- in einen Referenztyp durch ein Verfahren, das als Boxing bezeichnet wird.

Typen können ihrerseits Mitglieder enthalten: Felder, Eigenschaften, Methoden und Ereignisse. Dem Common Type System nur die Festlegung von Typen zuzuschreiben, würde die vielfältigen Aufgaben nur unzureichend beschreiben. Es gibt zudem die Regeln vor, nach denen die Sichtbarkeit dieser Typmitglieder festgelegt wird. Ein öffentlich deklariertes Mitglied eines vorgegebenen Typs könnte beispielsweise über die Grenzen der Anwendung hinaus sichtbar sein; andere Sichtbarkeiten beschränken ein Mitglied auf die aktuelle Anwendung oder sogar nur auf den Typ selbst.

Das vom Common Type System festgelegte Regelwerk ist grundsätzlich nichts Neues. Alle anderen Sprachen, auch die, die nicht auf .NET aufsetzen, weisen ein ähnliches Merkmal auf, um ein Typsystem in die Sprache zu integrieren. Aber es gibt einen entscheidenden Unterschied, in dem sich alle Sprachen der .NET-Umgebung vom Rest abheben: Während die Definition des Typsystems bei herkömmlichen Sprachen Bestandteil der Sprache selbst ist, wandert das .NET-Typsystem in die Laufzeitumgebung. Die Folgen sind gravierend: Kommunizieren zwei Komponenten miteinander, die in unterschiedlichen Sprachen entwickelt worden sind, sind keine Typkonvertierungen mehr notwendig, da sie auf demselben Typsystem aufsetzen.

Stellen Sie sich vor, eine Regelung durch das CTS würde es nicht geben. C# würde einen booleschen Typ definieren, der 2 Byte groß ist und C++.NET denselben Datentyp, der jedoch 4 Byte groß ist. Der uneingeschränkte Informationsaustausch wäre nicht möglich, sondern würde zu einem Merkmal der Sprache degradiert. Im gleichen Moment würde das ansonsten sehr stabile Framework wie ein Kartenhaus zusammenbrechen – eine fundamentale Stütze wäre ihm entzogen. Dieses Dilemma ist nicht unbekannt und beschert anderen Sprachen große Schwierigkeiten, Funktionen der WinAPI-32 direkt aufzurufen, beispielsweise Visual Basic 6.0

1.2.6 Das .NET Framework 

Ein Framework ist ein Oberbegriff für ein Gerüst, mit dem Anwendungen entwickelt, kompiliert und ausgeführt werden. Es setzt sich aus verschiedenen Richtlinien und Komponenten zusammen. Sie haben in den Abschnitten 1.2.4 und 1.2.5 mit der Common Language Specification (CLS) und dem Common Type System (CTS) bereits einen Teil des .NET Frameworks kennengelernt. Wir müssen aber dieses Anwendungsgerüst noch um zwei sehr wichtige Komponenten ergänzen:

die Common Language Runtime (CLR)

die .NET-Klassenbibliothek

Sie können in manchen Veröffentlichungen noch weitere Komponentenangaben finden, beispielsweise ADO.NET und ASP.NET. Es ist wohl mehr eine Sache der Definition, wo die Grenzen eines Frameworks gesetzt werden, da dieser Begriff nicht so klar umrissen ist. Die .NET-Klassenbibliothek ihrerseits stellt einen Oberbegriff dar, unter dem sich sowohl ADO.NET als auch ASP.NET eingliedern lassen.

1.2.7 Die »Common Language Runtime« (CLR) 

Die Common Language Runtime (CLR) ist die Umgebung, in der die .NET-Anwendungen ausgeführt werden – gewissermaßen die allen gemeinsame Laufzeitschicht. Der Stellenwert dieser Komponente kann nicht hoch genug eingestuft werden, denn mit ihren Fähigkeiten bildet die CLR den Kern von .NET.

Die CLR ist ein Verwalter. Dieses Wort ins Englische übersetzt heißt Manager. Tatsächlich wird der Code, der in der Common Language Runtime ausgeführt wird, auch als verwalteter Code bezeichnet – oder im Englischen als managed code. Umgekehrt kann mit dem Visual Studio 2005 auch unverwalteter Code geschrieben werden. In unverwaltetem oder unmanaged Code sind beispielsweise Treiberprogramme geschrieben, die direkt auf die Hardware zugreifen und deshalb plattformabhängig sind.

Sie müssen sich die Common Language Runtime nicht als eine Datei vorstellen, der eine bestimmte Aufgabe im .NET-Framework zukommt, wenn verwalteter Code ausgeführt wird. Vielmehr beschreibt die CLR zahlreiche Dienste, die als Bindeglied zwischen dem verwalteten IL-Code und der Hardware den Anforderungen des .NET Frameworks entsprechen und diese sicherstellen:

den Class Loader, der Klassen in die Laufzeitumgebung lädt

den Type Checker zur Unterbindung unzulässiger Typkonvertierungen

den JITter, der den MSIL-Code zur Laufzeit in nativen Code übersetzt, der im Prozessor ausgeführt werden kann

den Exception Manager, der die Ausnahmebehandlung unterstützt

den Garbage Collector, der eine automatische Speicherbereinigung anstößt, wenn Objekte nicht mehr benötigt werden

den Code Manager, der die Ausführung des Codes verwaltet

die Security Engine die sicherstellt, dass der User über die Berechtigung verfügt, den angeforderten Code auszuführen

die Debug Machine zum Debuggen der Anwendung

den Thread Service zur Unterstützung multithreadingfähiger Anwendungen

den COM Marshaller zur Sicherstellung der Kommunikation mit COM-Komponenten (COM = Component Object Model)

Die Liste ist zwar lang, vermittelt aber einen Einblick in die verschiedenen unterschiedlichen Aufgabenbereiche der Common Language Runtime.

1.2.8 Die .NET-Klassenbibliothek 

Das .NET Framework, das inzwischen in der Version 2.0 vorliegt, ist ausnahmslos objektorientiert ausgerichtet. Für Entwickler, die sich bisher erfolgreich dem objektorientierten Konzept widersetzt haben und mit sturer Beharrlichkeit auf prozeduralen Code gesetzt haben (solche gibt es häufiger, als Sie vielleicht vermuten), fängt die Zeit des Umdenkens an – es führt unter .NET kein Weg mehr daran vorbei.

Alles im .NET Framework wird als Objekt betrachtet. Dazu zählen sogar die nativen Datentypen der Common Language Specification wie der Integer. Die Folgen sind weitreichend, denn schon mit einer einfachen Deklaration wie

erzeugen wir ein Objekt mit allen sich daraus ergebenden Konsequenzen. Wir werden darauf in einem der folgenden Kapitel noch zu sprechen kommen.

Die .NET-Klassen stehen nicht zusammenhangslos im Raum, wie beispielsweise die Funktionen der WinAPI-32, sondern befinden sich ausnahmslos in einer engen Beziehung, der .NET-Klassenhierarchie. Eine Klassenhierarchie können Sie sich wie einen Familienstammbaum vorstellen, beim dem sich, ausgehend von einer Person, alle Nachkommen abbilden lassen. Auch die .NET-Klassenhierarchie hat einen Ausgangspunkt, gewissermaßen die Wurzel der Hierarchie: Es ist die Klasse Object. Jede andere Klasse des .NET Frameworks kann darauf zurückgeführt werden und erbt daher deren Methoden. Außerdem kann es weitere Nachfolger geben, die sowohl die Charakteristika der Klasse Object erben als auch die ihrer direkten Vorgängerklasse. Auf diese Weise bildet sich eine mehr oder weniger ausgeprägte Baumstruktur.

Für Visual C++-Programmierer ist eine Klassenhierarchie nichts Neues. Sie arbeiten bereits seit vielen Jahren mit der MFC (Microsoft Foundation Classes). Auch Java-Programmierer haben sich an eine ähnliche Hierarchie gewöhnen müssen.

Eine Klassenhierarchie basiert auf einer Bibliothek, die strukturiert ihre Dienste zum Wohle des Programmierers bereitstellt und letztendlich die Programmierung vereinfacht. Um allerdings in den Genuss der Klassenbibliothek zu kommen, muss man zuvor einiges tun – es ist ein erhöhter Lernaufwand erforderlich. Wenn man aber aus dieser Phase heraus ist, kann man sehr schnell und zielorientiert entwickeln, die anfänglichen Investitionen zahlen sich schnell aus.

Einen kurzen Überblick über den Inhalt der .NET-Klassenbibliothek zu geben, ist nur schwer, wenn nicht sogar vollkommen unmöglich, denn es handelt sich dabei um einige tausend vordefinierte Typen. Wenn man sich jetzt vorstellt, dass in jeder Klasse mehr oder weniger viele Methoden definiert sind, also Funktionen im prozeduralen Sinn, ist man sehr schnell bei Größenordnungen von einigen zehntausend Methoden, die insgesamt von den Klassen veröffentlicht werden. Alle zu kennen dürfte nicht nur an die Grenze der Unmöglichkeit stoßen, sondern diese sogar deutlich überschreiten. Außerdem kann man davon ausgehen, dass im Laufe der Zeit immer weitere Klassen mit zusätzlichen und verfeinerten Features in die Klassenhierarchie integriert werden – sowohl durch Microsoft selbst, als auch durch Drittanbieter.

1.2.9 Das Konzept der Namespaces 

Da jede Anwendung von Funktionalitäten lebt und der Zugriff auf die Klassenbibliothek zum täglichen Brot eines .NET-Entwicklers gehört, ist ein guter Überblick über die Klassen und insbesondere über deren Handling im Programmcode sehr wichtig. Hier kommt uns ein Feature entgegen, das die Arbeit deutlich erleichtert: Es sind die Namespaces. Ein Namespace ist eine logische Organisationsstruktur, die völlig unabhängig von der Klassenhierarchie eine Klasse einem bestimmten thematischen Gebiet zuordnet. Damit wird das Auffinden einer Klasse, die bestimmte Leistungsmerkmale aufweist, deutlich einfacher. Das Konzept ist natürlich auch nicht ganz neu. Ob Java wieder Pate gestanden hat, wissen wir nicht. Aber in Java gibt es eine ähnliche Struktur, die als Package bezeichnet wird.

Das Auffinden einer bestimmten Klasse ist nur ein Argument, was für die Namespaces spricht. Einem zweiten kommt eine ebenfalls nicht zu vernachlässigende Bedeutung zu. Jede Klasse ist durch einen Namen gekennzeichnet, der im Programmcode dazu benutzt wird, um daraus möglicherweise ein Objekt zu erzeugen und auf dessen Funktionalitäten zuzugreifen. Der Name muss natürlich eindeutig sein, schließlich können Sie auch nicht erwarten, dass ein Brief, der nur an Hans Fischer adressiert ist, tatsächlich den richtigen Empfänger erreicht. Namespaces verhindern Kollisionen zwischen identischen Klassenbezeichnern. Sie sind vergleichbar mit der vollständigen Adressierung eines Briefes. Nur innerhalb eines vorgegebenen Namespaces muss ein Klassenname eindeutig sein.

Die Namespaces sind auch wieder in einer hierarchischen Struktur organisiert. Machen Sie aber nicht den Fehler, die Klassenhierarchie mit der Hierarchie der Namespaces zu verwechseln. Eine Klassenhierarchie wird durch die Definition der Klasse im Programmcode festgelegt und hat Konsequenzen für die Fähigkeiten einer Klasse, bestimmte Operationen ausführen zu können, während die Zuordnung zu einem Namespace keine Auswirkungen auf die Fähigkeiten eines Objekts einer Klasse hat. Dass Klassen, die einem bestimmten Namespace zugeordnet sind, auch innerhalb der Klassenhierarchie eng zusammenstehen, ist eine Tatsache, die aus den Zusammenhängen resultiert, aber es ist kein Muss.

Wenn die Aussage, dass Namespaces in einer baumartigen Struktur organisiert werden zutrifft, muss es auch eine Wurzel geben. Diese heißt im .NET Framework System. Dieser Namespace organisiert die fundamentalsten Klassen in einem Verbund. Weiter oben habe ich erwähnt, dass sogar die nativen Datentypen wie der Integer auf Klassendefinitionen basieren – im Namespace System ist diese Klasse neben vielen weiteren zu finden. (Anmerkung: Falls Sie die Klasse jetzt aus Neugier suchen sollten – sie heißt nicht Integer sondern Int32.)

Unterhalb von System sind die anderen Namespaces angeordnet und namentlich so gegliedert, dass man schon erahnen kann, über welche Fähigkeiten die einem Namespace zugeordneten Klassen verfügen. Um ein Gefühl hierfür zu bekommen, sind in der nachfolgenden Tabelle auszugsweise ein paar Namespaces angeführt.

Die Tabelle gibt kaum mehr als einen Bruchteil aller .NET-Namespaces wieder. Sie sollten allerdings erkennen, wie hilfreich diese Organisationsstruktur bei der Entwicklung einer Anwendung sein kann. Suchen Sie die Lösung zu einem Problem, dann kanalisieren die Namespaces Ihre Suche und tragen so zu einer effektiveren Entwicklung bei.

Wir können in diesem Buch natürlich nicht alle Namespaces, geschweige denn alle Klassen des .NET-Frameworks behandeln. Ob das überhaupt jemals ein Buch zu leisten vermag, darf mehr als nur angezweifelt werden – zu umfangreich ist die Klassenbibliothek.

Sie sollten die wichtigsten Klassen und Namespaces kennen. Was zu den wichtigsten Komponenten gezählt werden kann, ist naturgemäß subjektiv. Ich werde mich daher auf diejenigen konzentrieren, die praktisch in jeder Anwendung von Belang sind bzw. bei jeder eigenen Klassendefinition in die Überlegung einbezogen werden müssen. In diesem Sinne werde ich mich auf die fundamentalen Bibliotheken beschränken, einschließlich der, die zur Entwicklung einer Windowsanwendung notwenig sind.